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Abstract 

This  paper  describes  the  authors’  efforts  to  develop  a  pedigree  ontology  for  level- 
one  sensor  fusion.  This  work  was  performed  in  the  context  of  naval  operations 
but  the  concepts  employed  are  applicable  to  any  domain  involving  sensor  fusion. 
The  ontology  that  has  been  developed  is  formally  represented  using  OWL,  the 
Web  Ontology  Language  used  in  defining  ontologies  for  the  Semantic  Web;  one 
advantage  of  using  OWL  is  that  it  has  a  formal  semantics  and  there  is  a  growing 
number  of  formal  systems  for  processing  and  reasoning  about  OWL-based 
documents.  The  paper  will  describe  the  pedigree  ontology  in  detail  along  with  the 
motivation  for  various  design  decisions.  An  example  will  be  given  of  the 
ontology’s  use  in  conjunction  with  OTH-T  GOLD  track  data;  in  a  simulated 
scenario  pedigree  information  permits  the  informed  selection  of  preferred  vessel 
tracks.  The  paper  concludes  with  a  discussion  of  open  issues  and  future 
directions. 


1.  Introduction 

Level-one  sensor  fusion  attempts  to  combine  data  collected  from  multiple  sensory 
sources  into  a  single  cohesive  description  of  the  sensed  characteristics  of  objects  in  an 
evolving  situation.  A  classic  example  of  this  sort  of  sensor  fusion  is  the  generation  of 
track  reports  including  data  regarding  location,  classification,  threat  identification,  etc. 
Sensors  come  in  a  variety  of  types  that  collect  passive  and/or  active  energy  in  the  form  of 
acoustic,  electro-optical  or  magnetic  radiation.  Each  sensor  type  comes  with  certain 
capabilities  as  well  as  inherent  limitations.  Even  within  a  given  type  there  can  be  a  wide 
range  of  capabilities  across  sensor  sub-types;  within  the  class  of  sonic  sensors,  for 
example,  the  capabilities  and  limitations  of  sonobuoys  vary  widely  from  those  of  towed- 
array  sensors  or  hull-mounted  sonar.  Furthermore,  a  specific  sensor  can  be  configured  in 
various  ways  (e.g.,  depth,  frequency,  direction),  it  may  be  of  a  specific  model  type  or 
version  having  certain  features  and  it  will  be  operating  under  specific  environmental 
conditions  that  may  affect  its  performance.  All  of  this  “meta-data”  describes  how  the  raw 
data  was  collected  and  contributes  to  what  is  usually  referred  to  as  the  data’s  pedigree  or 
provenance.  While  it  is  extremely  important  to  take  data  pedigree  into  consideration 
when  performing  level-one  fusion  there  has  been  surprisingly  little  done  to  date  to 
formalize  the  capture  and  representation  of  pedigree  information  in  this  domain  (for 
related  work  on  the  representation  and  use  of  data  pedigrees  in  the  sciences  see  [1,  2,  3]). 

In  this  paper  we  describe  our  efforts  to  develop  a  formal  pedigree  ontology  for  level-one 
sensor  fusion.  This  work  was  performed  in  the  context  of  naval  operations  but  the 
general  concepts  employed  are  applicable  to  any  domain  involving  sensor  fusion.  The 
ontology  that  has  been  developed  is  formally  represented  using  OWL4,  the  Web 
Ontology  Language  developed  for  the  Semantic  Web5.  One  advantage  of  using  OWL  is 
that  it  has  a  formal  semantics  that  permits  sound  and  complete  automated  reasoning. 
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Another  advantage  is  that  there  are  a  growing  number  of  practical  systems  for  processing 
and  reasoning  about  OWL-based  documents.  In  the  rest  of  this  paper  we  describe  our 
proposed  pedigree  ontology  in  detail  along  with  the  motivation  for  various  design 
decisions.  An  example  is  given  of  the  ontology’s  use  in  conjunction  with  OTH-T 
GOLD6  track  data  with  the  intent  of  being  able  to  make  a  more  informed  selection  of 
preferred  vessel  tracks.  The  paper  concludes  with  a  discussion  of  open  issues  and  future 
directions.  First,  however,  we  introduce  the  concept  of  ontologies  and  their  use  in  formal 
reasoning  systems. 

2.  The  Semantic  Web  and  Ontologies 

This  is  an  opportune  time  to  be  considering  the  potential  of  exploiting  pedigree 
information.  Meta-data  has  gained  renewed  emphasis  and  clout  in  various  domains,  both 
commercial  and  military.  It  has  also  become  a  hot  topic  in  the  computer  science  research 
community,  particularly  from  those  involved  with  the  development  of  the  Semantic  Web. 
The  goals  of  the  Semantic  Web  are  to  make  the  World  Wide  Web  as  accessible  to 
software  systems  and  intelligent  agents  as  it  is  today  to  humans.  The  current  contents  of 
Web  pages  are  very  difficult  for  computers  to  automatically  process  because  of  their  high 
reliance  on  natural  language  and  graphic  images,  which  computers  are  still  relatively 
poor  at  interpreting.  The  W3C’s  proposed  solution  is  to  annotate  Web  pages  with  meta¬ 
data  markup  that  describes  the  contents  of  a  page  in  terms  that  a  computer  can  readily 
process  and  “understand”. 

For  the  Semantic  Web  to  achieve  its  objectives  requires  a  formal  set  of  languages  and 
tools  for  representing  and  reasoning  about  information.  The  first  step  in  this  process  is 
the  development  of  a  language  for  defining  ontologies.  An  ontology  is  an  explicit,  formal, 
machine-readable  semantic  model  that  defines  the  classes  (or  concepts)  and  their  possible 
inter-relationships  pertinent  to  some  specific  domain.  To  construct  an  ontology  one  must 
have  an  ontology  specification  language.  As  part  of  its  Semantic  Web  effort,  the  W3C  has 
developed  the  OWL  Web  Ontology  Language,  which  is  XML-based  and  was  derived 
from  the  language  originally  developed  in  the  DARPA  Agent  Markup  Language 

' 7 

(DAML)  Project  .  OWL  is  rooted  in  the  fields  of  artificial  intelligence,  knowledge 

o 

representation  and  description  logics  .  It  is  a  mathematically  formal  language  for  logical 
representation  and  reasoning  with  a  well-established  formal  semantics9.  As  such,  it 
represents  the  most  advanced  state  of  the  art  in  languages  for  developing  formal 
ontologies  intended  for  the  use  in  defining  and  describing  a  large  class  of  meta¬ 
information. 

OWL  has  matured  to  the  level  where  it  can  serve  as  an  ideal  language  for  the  definition 
and  description  of  pedigree  data.  The  description  of  pedigree  information  alone, 
however,  does  not  represent  a  completely  satisfactory  solution  since  the  information  also 
needs  to  be  interpreted  and  operationalized;  this  requires  the  development  of  intelligent 
systems  that  can  automatically  process  the  OWL  ontologies  and  annotations  and  make 
logical  deductions  based  on  their  content.  While  OWL  is  great  for  representing  concepts 
and  their  properties,  it  is  limited  to  the  capabilities  of  description  logics  and  thus  does  not 
have  the  full  power  of  implication  one  would  expect  for  general-purpose  reasoning.  The 
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developers  of  OWL  were  well  aware  of  the  language’s  limitations  and  sought  ways  to 
extend  its  power  without  sacrificing  its  inherent  benefits.  Their  effort  resulted  in  the 
development  of  SWRL,  Semantic  Web  Rule  Language10,  first  released  in  the  fall  of  2003. 
SWRL  permits  the  specification  of  implication  rules  over  concepts,  properties  and 
instances  specified  using  OWL.  This  advancement  has  opened  the  door  to  much  more 
powerful  knowledge  representations  and  automated  inferencing  from  within  a  single 
formal  framework.  From  the  perspective  of  working  with  pedigrees  it  makes  it  possible  to 
define  pedigree  meta-data  for  specific  types  of  information  objects,  describe  instances  of 
the  pedigree  for  particular  instances  of  these  objects  (i.e.  annotations)  and  then  logically 
reason  about  what  implications  can  be  drawn  from  the  pedigree  information. 

There  are  a  number  of  challenges  to  effectively  implementing  information  pedigrees 
using  OWL  and  SWRL.  First,  there  is  the  knowledge  engineering  task  of  designing  an 
appropriate  pedigree  ontology  to  describe  the  concepts  and  properties  important  to  the 
definition  of  pedigrees.  This  requires  in-depth  experience  in  ontology  development, 
working  knowledge  of  the  strengths  and  limitations  of  OWL  and  a  thorough 
understanding  of  how  information  objects  are  processed  and  assembled.  Second,  one 
must  have  a  good  idea  for  how  the  information  captured  in  a  pedigree  ontology  might  be 
used  to  provide  some  advantage  during  the  use  of  the  information  objects.  There  is  no 
sense  in  constructing  a  pedigree  ontology  if  it  is  not  clear  that  the  meta-data  it  can  capture 
will  lead  to  measurable  benefits.  Third,  there  needs  to  be  a  way  to  represent  and  execute 
the  reasoning  processes  that  must  be  carried  out  to  make  effective  use  of  the  pedigree 
information  and  realize  the  anticipated  benefits.  This  requires  the  ability  to  capture 
domain  knowledge  in  the  form  of  SWRL  rules  and  then  systematically  apply  them  to 
OWL-based  pedigree  information.  Fourth,  there  must  be  an  effective  way  of  capturing 
and  distributing  pedigree  information.  This  will  require  the  development  of  pedigree 
annotation  tools  as  well  as  pedigree  servers.  In  this  paper  we  focus  on  the  first  challenge 
-  that  of  developing  a  formal  pedigree  ontology  in  OWL  -  while  our  ongoing  work 
continues  to  address  the  remaining  challenges. 

3.  An  Initial  Pedigree  Ontology 

The  motivation  for  developing  a  pedigree  ontology  came  from  a  need  to  process  and 
reason  about  OTH-T  GOLD6  contact  messages.  These  messages  contain  track 
information  pertaining  to  naval  vessels  derived  from  sensors  and  data  fusion  systems. 
While  the  messages  contain  useful  information  about  the  location,  bearing,  vessel  type 
and  likely  threat  they  contain  very  little  pedigree  information  about  how  the  contact 
message  was  created  other  than  the  source  organization  and  sensor  type.  Realizing  that 
there  was  a  lot  more  meta-data  that  could  be  communicated  about  how  contact  messages 
are  assembled,  we  set  out  to  develop  a  pedigree  ontology  that  could  capture  this 
information.  Our  initial  attempt  to  develop  such  an  ontology  is  shown  in 
Figure  1 .  The  intention  of  this  initial  version  was  to  capture  meta-data  about  how  a  single 
sensor  was  being  used  when  it  recorded  the  data  that  was  reported  in  an  OTH-T  GOLD 
message. 
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In  the  ontology  the  highest-level  concept  is  that  of  an  “information  object”  represented  by 
the  InfoObject  class.  InfoObjects  may  take  on  various  forms,  some  of  which  are 
represented  here  as  subclasses  (i.e.  Signal,  Track,  Report).  Associated  with  this 
InfoObject  is  its  pedigree  represented  by  a  class  called  InfoObjectMetaData.  The 
InfoObjectMetaData  contains  information  about  when  the  InfoObject  was  created  and 
what  its  source  was,  i.e.,  what  Sensor  reported  the  data.  This  class  also  contains  a 
property,  infoObjectConfiden.ee,  to  record  a  measure  of  the  confidence  that  should  be 
placed  on  this  InfoObject;  the  value  of  this  property  is  something  that  would  usually  be 
filled  in  by  a  program  that  analyzes  the  pedigree  information  to  determine  the  level  of 
confidence  that  should  be  attributed  to  the  data. 


Figure  1:  Initial  Pedigree  Ontology  for  Single  Sensors.  Rectangles  represent  classes,  large 
headed  arrows  depict  the  subclass  relation,  labeled  arrows  represent  properties  between  objects 
and  the  labels  within  class  rectangles  indicate  data  properties. 
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The  Sensor  class  captures  relevant  meta-data  about  the  Sensor,  specifically  how  it  was 
configured  and  under  what  conditions  it  was  operating  when  it  made  its  recording.  The 
type  of  sensor  that  was  used  is  determined  by  the  subclass  used  to  instantiate  it,  e.g., 
SonoBouy,  TowedArraySonar.  The  Sensor  class  has  been  subclassed  into 
ElectorOptical,  Acoustic  and  Magnetic  and  each  of  these  subclasses  is  expected  to  be 
further  subclassed  into  specific  sensor  subtypes,  as  we  have  patially  done  for  the  Acoustic 
class.  In  the  incomplete  ontology  shown  in  the  figure  we  have  focused  on  Acoustic 
SonoBouy  class  as  an  example  of  how  each  of  these  classes  would  be  further  fleshed  out 
in  a  more  complete  ontology.  For  the  type  of  Sonobouy  we  had  in  mind,  important 
properties  to  be  recorded  include  its  location  ( lat ,  long,  and  depth )  as  well  as  the 
frequency  it  was  operating  at. 

There  are  two  additional  properties  on  the  Sensor  class:  sensorTypeConfidence  and 
sensorlnstanceConfidence.  As  was  the  case  for  objectSourceConfidence  the  values  of 
these  properties  are  intended  to  be  filled  in  after  the  pedigree  information  has  been 
analyzed  either  by  a  program  or  humans  and  relative  confidence  levels  are  defined;  as 
such  they  may  represent  highly  subjective  values.  The  sensorTypeConfidence  property  is 
meant  to  capture  the  relative  confidence  one  has  in  the  entire  class  of  sensors  of  the  given 
type.  The  sensorlnstanceConfidence  captures  the  confidence  that  is  attributed  to  a 
specific  instance  of  the  sensor  type.  This  use  of  two  properties  may  be  valuable  in  the 
case  that  a  class  of  sensors  is  viewed  as  highly  reliable  but  a  given  instance  of  the  sensor 
has  recently  proven  to  be  much  less  reliable. 

4.  Refined  Pedigree  Ontology 

After  further  consideration  of  how  the  Pedigree  Ontology  might  be  used,  the  ontology 
was  refined  in  a  couple  of  ways;  these  enhancements  are  depicted  in  Figure  2.  First  of  all 
we  had  decided  to  work  with  the  C2  Information  Exchange  Data  Model  (C2IEDM)11 
developed  and  maintained  by  the  Multilateral  Interoperability  Programme  (MIP). 
C2IEDM  (also  referred  to  as  the  “Generic  Hub”  and  soon  to  become  the  JC3IEDM  — 
Joint  C3  Information  Exchange  Data  Model)  is  a  NATO  standard  for  exchanging  military 
information  among  multi-national  allied  forces.  Since  we  had  developed  an  OWL-based 
C2IEDM  ontology  (see  [12])  for  this  same  R&D  effort  we  needed  to  integrate  the 
pedigree  ontology  with  the  C2IEDM  ontology.  In  the  C2IEDM  ontology  the  small 
amount  of  pedigree  information  that  it  permits  is  captured  in  the  Reporting-Data  class. 
To  incorporate  our  pedigree  ontology  we  have  added  informationObjectConfidence  and 
infoOjectSource  properties  to  this  Reporting-Data  class,  which  takes  the  place  of  our 
former  InfoObjectMetaDataClass.  Since  we  are  not  changing  the  Reporting-Data  class 
but  merely  extending  it  this  is  consistent  within  the  intended  extensible  use  of  the 
C2IEDM  data  model. 

Second,  in  considering  more  complex  situations,  it  became  evident  that  we  would  need  to 
be  able  to  talk  about  information  that  was  derived  from  multiple  sensors,  for  example 
when  the  track  from  one  sensor  is  correlated  with  that  from  another  sensor.  Since  this 
form  of  data  fusion  must  be  done  by  either  a  System  or  a  Human,  we  added  these  two 
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classes  to  the  ontology.  If  the  fusion  is  done  by  a  System  then  it  will  have  its  associated 
Software  with  its  possible  parameter  Settings.  Note  that  the  System  class  is  now  the 
parent  of  the  Sensor  class,  which  remains  otherwise  unchanged.  The  ontology  could 
readily  be  extended  to  deal  with  more  involved  details  about  Human  and  Human-System 
produced  information  sources,  but  for  our  current  effort  it  seemed  prudent  to  focus  on  the 
systems  side  alone. 


Figure  2:  Refined  Pedigree  Ontology  with  Link  to  C2IEDM  Reporting-Data  Class.  Rectangles 
represent  classes,  large  headed  arrows  depict  the  subclass  relation,  labeled  arrows  represent 
properties  between  objects  and  the  labels  within  class  rectangles  indicate  data  properties. 


5.  Pedigree  Sources 

Having  a  pedigree  ontology  is  not  very  useful  unless  you  have  sources  for  the  pedigree 
information  and  ways  of  attaching  the  information  they  provide  to  the  corresponding 
information  objects.  Other  than  the  limited  amount  of  pedigree  data  that  currently  comes 
in  OTH-T  GOLD  messages  (e.g.,  sensor  id)  there  is  no  standard  for  how  to  add  additional 
meta-data  to  the  messages.  It  is  possible  however  to  add  remarks  to  OTH-T  GOLD 
messages  using  the  RMKS  line.  Using  this  line  we  could  hypothesize  that  a  new  sensor 
has  become  available  that  is  designed  to  send  pedigree  information  encapsulated  in 
structured  fields  with  one  or  more  RMKS  lines  following  a  CTC  (i.e.,  contact)  or  POS 
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(i.e.,  position)  line  of  an  OTH-T  GOLD  message.  One  such  structured  format  approach 
based  on  our  pedigree  ontology  is  as  follows: 

RMKS/PDGRE/reportedBy/date/time/sourceType 

RMKS/PDGRE/SNSR  Hd/sensorType/active?/status/depth/lat/long/freq 

RMKS/PDGRE/SFT/title/version/paraml/param2/parm3 

RMKS/PDGRE/ENV /temp/salinity/current/gradlDepth/grad2Depth 

This  message  structure  depicts  a  subset  of  a  more  complete  format  definition  that  could 
be  developed.  In  this  subset  we  show  how  in  the  first  line  a  pedigree  (PDGRE)  remark 
could  convey  the  critical  information  about  who  reported  the  CTC,  when  it  was  reported 
and  the  source  of  the  reported  information  (some  of  this  is  redundant,  obviously,  with 
what  is  in  the  CTC  line).  The  second  line  provides  specific  information  about  the  sensor 
(SNSR)  that  was  used.  The  third  line  describes  the  software  (SFT)  operating  on  the 
sensor  and  the  final  line  describes  the  environmental  (ENV)  conditions  at  the  time  of  the 
recording. 

An  alternative  approach  to  providing  pedigree  information  to  information  systems  is  to 
assume  that  all  pedigree  information  is  collected,  maintained  and  distributed  by  either  a 
centralized  or  distributed  Pedigree  Service.  In  such  a  case  the  pedigree  information  for 
an  information  object  could  be  queried  from  this  service  by  providing  it  with  the  time  and 
id  of  the  sensor/system  that  provided  the  data.  In  this  way  a  system  analyzing  data  from 
information  objects  could  obtain  the  most  up-to-date  pedigree  data  available.  This  has 
some  advantage  in  that  within  this  approach  the  OTH-T  GOLD  track  data  does  not  have 
to  be  altered  in  any  way.  On  the  down  side,  it  assumes  the  establishment  of  a  broad 
based  service  having  access  to  current  operational  characteristics  of  all  sensors  and 
systems  in  operation.  This  approach  is  seems  rather  infeasible,  as  it  calls  for  a  massive 
development  effort  and  huge  changes  in  the  current  infrastructure  to  permit  the  detailed 
monitoring  of  all  sensors  and  systems. 

An  alternative  to  the  two  identified  approaches  is  a  hybrid  solution.  One  feature  the  first 
approach  lacks  is  the  ability  to  record  the  track  record  of  systems,  sensors  and  humans 
(i.e.,  how  well  they  have  performed  over  time).  This  type  of  meta-data  may  well  prove  to 
be  some  of  the  most  valuable  types  of  pedigree  information  -  knowing  for  example  that  a 
given  track  was  produced  under  the  direction  of  the  Navy’s  top  sonar  operator  may  make 
it  more  valuable  than  a  track  produced  by  a  couple  of  sonobouys  that  have  proven  in  the 
past  to  have  wide  error  margins  under  the  environmental  conditions  they  are  currently 
experiencing.  One  could  augment  OTH-T  GOLD  data  with  some  pedigree  information 
as  described  above  and  in  addition  provide  access  to  a  centralize  Pedigree  Service  that 
could  distribute  meta-data  about  the  historical  performance  and  compiled  confidence 
levels  established  for  the  information  sources.  Such  a  service  could  in  fact  permit 
individual  users  to  form  their  own  confidence  measures  for  various  systems  and  humans, 
and  they  could  even  base  these  on  the  profiles  created  by  others  in  the  system  (e.g.,  more 
experienced  commanders). 
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6.  A  Naval  Scenario 

In  developing  the  various  aspects  of  the  pedigree  ontology  it  was  valuable  to  have  a 
scenario  to  help  ground  the  concepts.  The  general  idea  behind  our  working  scenario  is  to 
attempt  to  track  a  small  pack  of  submarines  using  a  collection  of  sonobouys  and  towed 
array  sonar.  Each  sensor  will  be  uniquely  located,  may  be  configured  with  different 
settings/orientations  and  may  be  operating  under  different  environmental  conditions. 
This  set  of  meta-data  about  where  and  how  a  sensor  is  functioning  will  contribute  to  the 
sensor’s  pedigree.  Each  sensor  will  provide  track  information  for  one  or  more  of  the 
submarines  resulting  in  multiple  tracks  for  each  submarine.  The  goal  is  to  use  pedigree 
information  to  help  in  determining  which  track  or  which  set  of  fused  tracks  should  be 
taken  to  be  the  most  reliable.  For  the  sake  of  this  scenario  we  assume  that  the  identity  of 
the  submarine  described  by  each  track  from  each  of  the  sensor  is  unique  and  correct. 


track  source 
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Negotiation 
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track  source 
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Figure  3:  Concept  for  Enhancing  Track  Selection  through  Pedigree  Reasoning  using  an 
Architecture  based  on  the  SIXA  Methodology. 


The  general  concept  for  the  scenario,  along  with  its  high  level  architecture  based  on  the 

i  a 

SIXA  Methodology  ,  is  depicted  in  Figure  3.  The  architecture  includes  three  Semantic 
Information  Services  (SIS):  two  information  producers  -  the  Pedigree  SIS  and  the  OTH- 
T  GOLD  SIS  -  and  one  consumer  -  the  Track  Displayer  SIS.  The  OTH-T  GOLD  SIS 
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provides  track  information  annotated  according  to  the  C2IEDM  Track  Ontology.  The 
Track  Displayer  SIS  negotiates  with  the  OTH-T  GOLD  SIS  to  request  specific  track 
information,  for  example  tracks  for  a  given  region  or  tracks  for  a  certain  type  of 
platforms.  After  a  successful  negotiation  the  OTH-T  GOLD  SIS  would  begin  sending  the 
Track  Display  SIS  a  continuous  stream  of  relevant  track  data.  This  track  data  would  be 
enhanced  over  normal  OTH-T  GOLD  data  in  that  it  would  have  some  additional  pedigree 
information  embedded  within  each  contact.  The  Track  Displayer  SIS  would  also 
negotiate  with  the  Pedigree  Server  SIS  for  historical  and  credibility  information  regarding 
the  sensors  that  it  is  receiving  track  data  from.  Requests  made  to  the  Pedigree  SIS  would 
be  simple  one-time  queries  and  would  not  require  a  data  stream  connection  as  is 
employed  with  the  OTH-T  GOLD  SIS. 

The  Track  Displayer  SIS  would  be  capable  of  displaying  all  of  the  track  data  that  it 
receives  from  the  OTH-T  GOLD  SIS,  but  it  would  also  be  able  to  provide  an  enhanced 
view  on  the  track  information  that  would  assign  relative  confidence  ratings  to  the  various 
tracks  based  on  reasoning  about  the  pedigrees.  In  the  diagram  the  monitoring  screen 
shown  at  the  bottom  suggests  that  tracks  for  the  same  vessel  but  coming  from  different 
sources  could  be  displayed  differently  according  to  the  level  of  confidence  the  reasoner 
was  able  to  derive  from  their  pedigrees;  this  display  would  also  be  interactive  permitting 
the  operator  to  turn  off  or  adjust  the  pedigree-based  display  as  well  as  query  it  for 
explanations  about  the  reasoning  behind  the  assigned  confidence  ratings.  This  reasoning 
would  take  place  using  a  combination  of  ontological  reasoning  and  rules-based  reasoning 
which  would  capture  domain  knowledge  about  how  sensors  operate  and  could 
incorporate  generic  and  learned  confidence  ratings  for  various  types  of  sensors  and  sensor 
configurations. 

7.  Conclusions 

In  this  paper  we  described  our  efforts  to  develop  a  pedigree  ontology  using  the  OWL 
Web  Ontology  Language.  The  ontology  is  designed  to  capture  meta-data  concerning  the 
conditions  and  circumstances  under  which  level- 1  sensor  data  is  collected  and  processed. 
Our  focus  for  this  ontology  was  on  Naval  operations,  specifically  concerning  the  use  of 
OTH-T  GOLD  contact  messages  for  describing  track  of  Naval  vessels.  Our  interest  in 
developing  this  ontology  is  to  improve  the  ability  to  interpret  and  evaluate  track  data, 
particularly  in  the  case  where  information  about  a  vessel  is  obtained  from  multiple 
sources  and  choices  need  to  be  made  about  the  validity  of  conflicting  data14.  We 
described  a  scenario  in  which  pedigree  information  encoded  using  the  proposed  ontology 
could  assist  an  automated  reasoning  system  in  selecting  the  most  reliable  track  data.  We 
are  in  the  process  of  designing  and  prototyping  such  a  system  as  part  of  our  current  work 
with  the  Office  of  Naval  Research. 

One  challenge  to  the  use  of  pedigree  information  is  the  relative  lack  of  support  for 
gathering  and  distributing  such  information.  Both  OTH-T  GOLD  and  C2IEDM  have 
very  limited  built-in  capabilities  for  representing  pedigree  information.  Lortunately,  both 
formats  provide  means  for  extending  their  representational  capabilities,  with  C2IEDM 
being  explicitly  designed  to  be  extended  and  OTH-T  GOLD  providing  some  rudimentary 
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capacity  for  extension  through  the  use  of  structured  remark  lines.  It  is  anticipated  that  as 
these  formats  evolve  or  are  replaced  with  more  modern  representations  that  support  for 
pedigree  information  will  improve  and  become  commonplace.  Ideally,  these 
representations  will  leverage  some  of  the  advantages  afforded  by  the  use  of  XML  and 
ontology-based  languages  such  as  OWL  and  SWRL.  Adoption  of  these  modem 
languages  will  greatly  facilitate  the  design  and  development  of  advanced  automated 
systems  with  human-like  reasoning  capabilities  that  can  be  formally  verified  and  trusted 
to  provide  sound  results. 
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Appendix  A:  Pedigree  Ontology  in  OWL 


<?xml  version='T.0"?> 

<rdf:RDF 

xmlns="http://a.com/ontology#" 

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 

xmlns:owl="http://www.w3.org/2002/07/owl#" 

xml:base="http://a.com/ontology"> 

<owl:Ontology  rdf:about=""/> 

<owl:Class  rdf:ID="ElectroOptical"> 

<rdfs :  subClas  sOf> 

<owl:Class  rdf:about="#Sensor"/> 

</rdfs:subClassOf> 

</owl:Class> 

<owl:Class  rdf:ID="Reporting-Data"/> 

<owl:Class  rdf:ID="InfoSource"/> 

<owl:Class  rdf:ID="SonoBuoy"> 

<rdfs:subClassOf> 

<owl:Class  rdf:about="#Acoustic"/> 

</rdfs:subClassOf> 

</owl:Class> 

<owl:Class  rdf:ID="Acoustic"> 

<rdfs:subClassOf> 

<owl:Class  rdf:about="#Sensor"/> 

</rdfs:subClassOf> 

</owl:Class> 

<owl:Class  rdf:ID="Software"/> 

<owl:Class  rdf:ID="System"> 

<rdfs:subClassOf  rdf:resource="#InfoSource"/> 
</owl:Class> 

<owl:Class  rdf:ID="Human"> 
crdfs :  subClas  sOf  rdf  :resource="#InfoS  ource  "/> 
</owl:Class> 

<owl:Class  rdf:ID="TowedArraySonar"> 

<rdfs:subClassOf  rdf:resource="#Acoustic"/> 

</owl:Class> 

<owl:Class  rdf:ID="Setting"/> 

<owl:Class  rdf:ID="CoorelationSystem"> 

<rdfs:subClassOf  rdf:resource="#System"/> 

</owl:Class> 

<owl:Class  rdf:ID="Sensor"> 

<rdfs:subClassOf  rdf:resource="#System"/> 

</owl:Class> 

<owl:Class  rdf:ID="Magnetic"> 

<rdfs:subClassOf  rdf:resource="#Sensor"/> 
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</owl:Class> 

<owl:Class  rdf:ID="Environment"/> 

<owl:Class  rdf:ID="HullMountedSonar"> 

<rdfs:subClassOf  rdf:resource="#Acoustic"/> 

</owl:Class> 

<o wl:  Clas  s  rdf :  ID=" W aterConditions  "> 

<rdfs:subClassOf  rdf:resource="#Environment"/> 

</owl:Class> 

<owl:ObjectProperty  rdf:ID="cnvi ronmcnt"> 

<rdfs:range  rdf:resource="#Environment"/> 

<rdfs:domain  rdf:resource="#Sensor"/> 

</o  wl :  Obj  ectProperty> 

<owl:ObjectProperty  rdf:ID="infoObjectSource"> 

<rdfs:domain  rdf:resource="#Reporting-Data"/> 

<rdfs:range  rdf:resource="#InfoSource"/> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/> 
</o  wl :  Obj  ectProperty> 

<owl:ObjectProperty  rdf:ID="softwareUsed"> 

<rdfs:range  rdf:resource="#Software"/> 

<rdfs:domain  rdf:resource="#System"/> 

</owl:  ObjectProperty> 

<owl:ObjectProperty  rdf:ID="parameterSetting"> 

<rdfs:range  rdf:resource="#Setting"/> 

<rdfs:domain  rdf:resource="#Software"/> 

</o  wl :  Obj  ectProperty> 

<o  wl :  Obj  ectProperty  rdf :  ID= "pedigree "  > 

<rdfs:range  rdf:resource="#Reporting-Data"/> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/> 
</o  wl :  Obj  ectProperty> 

<o  wl :  DatatypeProperty  rdf :  ID= "  version "  > 

<rdfs:domain  rdf:resource="#Software'7> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#string'7> 

</o  wl :  DatatypeProperty> 

<o wl :  DatatypeProperty  rdf :  ID="deptli"> 

<rdfs:domain  rdf:resource="#SonoBuoy'7> 

<rdfs:range  rdf:resource="http7/www.w3.org/2001/XMLSchema#float'7> 
</owl:DatatypeProperty> 

<o wl :  DatatypeProperty  rdf :  ID="sensorTypeConfidence  "> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty'7> 
<rdfs:domain  rdf:resource="#Sensor"/> 

<rdfs:range  rdf:resource="http7/www.w3.org/2001/XMLSchema#int'7> 
</owl:DatatypeProperty> 

<o wl :  DatatypeProperty  rdf :  ID=" value  "> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty'7> 
<rdfs:range  rdf:resource="http7/www.w3.org/2001/XMLSchema#string'7> 
<rdfs:domain  rdf:resource="#Setting'7> 
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</o  wl:  DatatypeProperty> 

<owl:DatatypeProperty  rdf:ID="reporting-data-reporting-date"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> 
<rdfs:domain  rdf:resource="#Reporting-Data"/> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/> 
</o  wl:  DatatypeProperty> 

<o  wl :  DatatypeProperty  rdf :  ID="name  "> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> 
<rdfs:domain  rdf:resource="#Setting"/> 

</o  wl :  DatatypeProperty> 

<o wl :  DatatypeProperty  rdf :  ID="latatude  "> 

<rdfs:domain  rdf:resource="#SonoBuoy"/> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> 
</owl:DatatypeProperty> 

<owl:  DatatypeProperty  rdf:ID="detectionStatus"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> 
<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/> 
<rdfs:domain  rdf:resource="#Sensor'7> 

</o  wl:  DatatypeProperty> 

<o wl :  DatatypeProperty  rdf :  ID= " title " > 

<rdfs:domain  rdf:resource="#Software'7> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#string'7> 
</owl:DatatypeProperty> 

<o wl :  DatatypeProperty  rdf :  ID="sensorInstanceConfidence  "> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty'7> 
<rdfs:domain  rdf:resource="#Sensor'7> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#int'7> 

</o  wl:  DatatypeProperty> 

<owl:FunctionalProperty  rdf:ID="is-reported-by"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI'7> 
<rdfs:domain  rdf:resource="#Reporting-Data'7> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty'7> 
</o  wl:  FunctionalProperty> 

<owl:FunctionalProperty  rdf:ID="active"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#boolean'7> 
<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty'7> 
<rdfs:domain  rdf:resource="#SensorM/> 

</o  wl:  FunctionalProperty> 

<owl:FunctionalProperty  rdf:ID="longitude"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#float'7> 
<rdfs:domain  rdf:resource="#SonoBuoy'7> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty'7> 
</o  wl:  FunctionalProperty> 

<owl:FunctionalProperty  rdf:ID="sensorId"> 

<rdfs:domain  rdf:resource="#Sensor'7> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#string'7> 
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<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> 
</o  wl:  FunctionalProperty> 

<owl:FunctionalProperty  rdf:ID="reporting-data-reporting-time"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#time"/> 
<rdfs:domain  rdf:resource="#Reporting-Data"/> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> 
</owl:FunctionalProperty> 

<owl:FunctionalProperty  rdf:ID="infoObjectConfidence"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#int'7> 
<rdfs:domain  rdf:resource="#Reporting-Data'7> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty'7> 
</o  wl:  FunctionalProperty> 

<owl:FunctionalProperty  rdf:ID="frequency"> 

<rdfs:range  rdf:resource="http://www.w3.org/2001/XMLSchema#float'7> 
<rdfs:domain  rdf:resource="#SonoBuoy'7> 

<rdf:type  rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty'7> 
</o  wl:  FunctionalProperty> 

</rdf:RDF> 
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